Fundamentally, a software application is a set of instructions that can be followed by a computer to perform one or more tasks. Traditionally, a software application was designed by identifying the task(s) to be performed and writing instructions to perform those tasks in a programming language, such as C or C++. The disadvantage to this traditional approach is that it requires the software developer to model the development process in terms of the low-level actions that a computer can be instructed to perform, rather than in terms of the contemplated use of the software by actual business users. For example, if the software to be developed is an organization-wide scheduling system for a university, the traditional approach to software development may require the developer to model the problem in terms of how calendars are represented as data structures and manipulated arithmetically, how users are uniquely identified within the system, etc. This type of model for the software is at a much “lower-level” than the business problem that the software is intended to solve.
Software development tools, such as the RATIONAL ROSE visual modeling tool from Rational Software Corporation, seek to improve on the traditional software development process by allowing the function of the software to be modeled at a relatively higher level of abstraction. With RATIONAL ROSE, instead of modeling the requirements for software in terms of the basic actions to be performed by a computer, a software developer can abstract the software under development in terms of “use cases” and object models. A “use case” is an instance of the use of the software by an actor. For example, in the scheduling system mentioned above, a use case might be a calendar owner's scheduling of a personal appointment on his or her calendar. Having identified one or more such use cases, the software developer can build the software by separately modeling and then coding each of the use cases.
Use cases are a useful abstraction because they allow the software developer to create software with a view toward specific situations that the software will be expected to handle. However, use cases still have the drawback of being, in many situations, at a much lower level of abstraction than the requirements for which the software is designed. Software is generally envisioned to meet the requirements of a business model, and a business model is usually conceived as a high-level plan to implement a business process, rather than as a collection of specific examples of how the software will be used. For example, the management of a university (which, in many cases, is composed of a group of non-programmers) may envision a scheduling system that meets certain requirements and solves certain scheduling problems. However, the management's vision for such a system is not likely to be at a level of detail that includes all of the exemplary uses of the system (e.g., scheduling a personal appointment, scheduling a university-wide event, canceling an appointment, deleting from the system a user who has left the university, etc.). The programmers who will ultimately implement the system, however, need to understand the lower-level use cases in order to implement a system that will meet all of the high-level requirements of the system. In this sense, there is often a disconnect between the language of the business people who envision the software and the needs of the programmers who design and implement the system. This disconnect may result in the software developers' failure to capture all of the use cases because they do not fully appreciate the nature of the business process that they will implement. Alternatively, the disconnect may result in software that does not quite meet the task for which it was created because the development process is driven more by the programmers' need to “fit” a business process onto a set of use cases, rather than the need to capture the true essence of the business process in the form of software.
In view of the foregoing, there is a need for a software development tool that overcomes the drawbacks of the prior art.